> years ago, hence my assumption. then again, i recently spotted an o ld > sendmail hole ("wizard") at a site, so one can never really assume a nything, That reminds me... browing the results of running the uksm config stuff (2.1) I noticed the Wizards password entry in sendmail.cf. I've scaned all the docs I've got and I'm still ignorant - so what is it for? Can I simply remove it? Yes, you can remove it. The story of the ``wizard'' hole is quite interesting; it's a good lesson in how the interaction of features can cause truly horrendous results. Sendmail uses large and truly horrendous configuration files. Everything, it seems, can be tweaked that way. In older versions, to avoid the overhead of reading and parsing that mess each time, there was something known as a ``frozen'' configuration file. (Some vendors still support it, btw; Eric Allman has quite rightly removed that feature from recent releases.) The frozen configuration file was intended as just a compiled version; as such, there's nothing wrong with the concept. But it was implemented in a very unclean fashion. And to understand it, it's necessary for me to digress and review the structure of a executable program in UNIX. Executable files are composed of three sections: text, data, and bss. Text is the actual machine code, initialized variables are in the data section, while bss is used for variables which are not explicitly initialized by the (C language) programmer; by definition of the language, these must be set to zero, so UNIX clears the bss area before transferring control to the program. Note that the bss area does not take up any space in the file. Finally, when executing, programs can allocate memory dynamically using the sbrk() system call (to which malloc() is the usual interfac). This area resides immediately above the bss area in memory, at least in classic versions of UNIX. When sendmail read in its configuration file, dynamic storage was used to hold all of the necessary data structures. The configuration file was frozen by writing out the bss area and the currently-allocated dynamic memory area. (Yes, this is horribly compiler- and system-dependent. And yes, other things, such as stdio's data structures and buffers were written out as well. See my editorial comments above.) As I recall -- and it's been a fair number of years -- the wizard mode feature was implemented by two variables, a flag saying that there was a password (and hence that the feature was to be enabled), and a pointer to the hashed password that was read from the configuration file. The crucial bug was in the declaration of the pointer to the hashed password: char *wizpw = NULL; It was explicitly initialized, albeit to 0 -- and as such, it resided in the data area, not the bss area. It was thus not written out to the frozen configuration file. When sendmail was running in its normal production state, it appeared that wizard mode was enabled -- the flag was in the frozen section -- but that there was no password. Anyone who connected to the mailer port could type ``wiz'' and get all sorts of privileges, notably an interactive shell. But when the code was being developed, the password was tested -- and it worked. After all, you test code when you add it, and you can't use an old frozen config file when you've just recompiled; the bss area layout is different. So the wizard mode password always worked in testing, but never in production.